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Mission  Impact  of  Foreign 
Influence  on  DoD  Software 


Defense  Science  Board  Task  Force 


The  Defense  Science  Board  task  force  assessed  the  Department  of  Defense’s  (DoD)  dependence  on  software  of  foreign  origin 
and  the  risks  involved.  The  task  force  considered  issues  with  supply  chain  management;  techniques  and  tools  to  mitigate  adver¬ 
sarial  threats;  software  assurance  within  current  DoD  programs;  and  assurance  standards  within  industry,  academia,  and 
government.  This  executive  summary  highlights  the  future  U.S.  ahilily  to  ensure  and  maintain  a  trusted  supply  of  software 
to  the  DoD  and  the  U.S.  government.  The  full  report  states  that  there  is  no  absolute  guarantee  that  software  can  be  sani¬ 
tised  of  all  vulnerabilities,  intended  or  unintended,  and  recommends  a  suite  of  processes  and  mitigation  strategies  to  reduce 
the  risk  of  interrupted  systems  performance  and  ensure  mission  success. 


Software  has  become  the  central  ingre¬ 
dient  of  the  information  age,  increas¬ 
ing  productivity,  facilitating  the  storage 
and  transfer  of  information,  and  enabling 
functionality  in  almost  every  realm  of 
human  endeavor.  However,  as  it  improves 
the  DoD  capability,  it  increases  the  DoD’s 
dependency.  Each  year  the  DoD  depends 
more  on  software  for  its  administration 
and  for  the  planning  and  execution  of  its 
missions.  This  growing  dependency  is  a 
source  of  weakness  exacerbated  by  the 
mounting  size,  complexity  and  intercon¬ 
nectedness  of  its  software  programs.  It  is 
only  a  matter  of  time  before  an  adversary 
exploits  this  weakness  at  a  critical  moment 
in  history. 

The  software  industry  has  become 
increasingly  and  irrevocably  global.  Much 
of  the  code  is  now  written  outside  the 
United  States,  some  in  countries  that  may 
have  interests  inimical  to  those  of  the 
United  States.  The  combination  of  the 
DoD’s  profound  and  growing  dependence 
upon  software  and  the  expanding  oppor¬ 
tunity  for  adversaries  to  introduce  mali¬ 
cious  code  into  this  software  has  led  to  a 
growing  risk  to  the  nation’s  defense. 

A  previous  report  of  the  Defense 
Science  Board,  “High  Performance 
Microchip  Supply,”  discussed  a  parallel 
evolution  of  the  microchip  industry  and 
its  potential  impact  on  U.S.  defense  capa¬ 
bilities.  The  parallel  is  not  exact  because 
the  microchip  fabrication  business 
requires  increasingly  large  capital  forma¬ 
tion  -  a  considerable  barrier  to  entry  by  a 
lesser  nation-state.  Software  development 
and  production,  by  contrast,  has  a  low 
investment  threshold.  It  requires  only  tal¬ 
ented  people,  who  increasingly  are  found 
outside  the  United  States. 

The  task  force  on  microchip  supply 
identified  two  areas  of  risk  in  the  off¬ 
shoring  of  fabrication  facilities  -  that  the 
United  States  could  be  denied  access  to 


the  supply  of  chips  and  that  there  could 
be  malicious  modifications  in  these  chips. 
Because  software  is  so  easily  reproduced, 
the  former  risk  is  small.  The  latter  risk  of 
malware,  however,  is  serious.  It  is  this  risk 
that  is  discussed  at  length  in  this  report. 

Software  that  the  DoD  acquires  has 
been  loosely  categorized  as: 

•  Commodity  products  -  referred  to  as 
commercial  off-the-shelf  (COTS) 
software. 

•  General  software  developed  by  or  for 
the  U.S.  government  -  referred  to  as 
government  off-the-shelf  software. 

•  Custom  software  -  generally  created 
for  unique  defense  applications. 

The  U.S.  government  is  obviously 
attracted  by  the  first,  COTS.  It  is  pro¬ 
duced  for  and  sold  in  a  highly  competitive 
marketplace  and  its  development  costs  are 
amortized  across  a  large  base  of  con¬ 
sumers.  Its  functionality  continually 
expands  in  response  to  competitive  mar¬ 
ket  demands.  It  is,  in  a  word,  a  bargain,  but 
it  is  also  most  likely  to  be  produced  off¬ 
shore  and  so  presents  the  greater  threat  of 
malicious  modification. 

There  are  two  distinct  kinds  of  vulner¬ 
abilities  in  software.  The  first  is  the  com¬ 
mon  bug,  an  unintentional  defect  or  weak¬ 
ness  in  the  code  that  opens  the  door  to 
opportunistic  exploitation.  The  DoD 
shares  these  vulnerabilities  with  all  users. 
However,  certain  users  are  high  value  targets, 
such  as  tire  financial  sector  and  the  DoD. 
These  high-value  targets  attract  the  high- 
end  attackers.  Moreover,  the  DoD  also  may 
be  presumed  to  attract  the  most  skilled 
and  best-financed  attackers  -  a  nation¬ 
state  adversary  or  its  proxy.  These  high- 
end  attackers  will  not  be  content  to  exploit 
opportunistic  vulnerabilities  which  might 
be  fixed  and  therefore  unavailable  at  a  crit¬ 
ical  juncture.  Furthermore,  they  may  seek 
to  implant  vulnerability  for  later  exploita¬ 
tion.  It  is  bad  enough  that  this  can  be  done 


remotely  in  the  internetworked  world,  but 
worse  when  the  malefactors  are  in  the 
DoD’s  supply  chain  and  are  loyal  to  and 
working  for  an  adversary  nation-state  — 
especially  a  nation-state  that  is  producing 
the  software  that  the  U.S.  government 
needs.  The  problem  is  serious,  indeed. 
Such  exploitable  vulnerabilities  may  lie 
undetected  until  it  is  too  late. 

Unlike  previous  critical  defense  tech¬ 
nologies  which  gave  the  U.S.  an  edge  in 
the  past,  such  as  stealth,  tire  strategic 
defense  initiative,  or  nuclear  weaponry,  the 
U.S.  is  protected  neither  by  technological 
secrets  nor  a  high  barrier  of  economic 
cost.  Moreover,  the  consequences  to  U.S. 
defense  capabilities  could  be  even  more 
severe  than  realized.  Because  of  the  high 
degree  of  interconnectedness  of  defense 
systems,  penetration  of  one  application 
could  compromise  many  others. 

In  a  perfect  world  there  would  be 
some  automated  means  for  detecting  mali¬ 
cious  code.  Unfortunately,  no  such  capa¬ 
bility  exists,  and  the  trend  is  moving  inex¬ 
orably  further  from  it  as  software 
becomes  ever  more  complex  and  adver¬ 
saries  more  skilled.  Even  if  malicious  code 
were  discovered  in  advance,  attributing  it 
to  a  specific  actor  and/or  knowing  the 
intent  of  the  actor  may  be  problematic. 
Malicious  code  can  resemble  ordinary 
coding  mistakes  and  malicious  intent  may 
be  plausibly  denied.  The  inability  to  hold 
an  individual  accountable  weakens  deter¬ 
rence  mechanisms,  such  as  the  threat  of 
criminal  charges,  or  even  separation  of  the 
individual  or  entity  from  the  supply  chain. 

Task  Force  Conclusion 

The  DoD  faces  a  difficult  quandary  in  its 
software  purchases  in  applying  intelligent 
risk  management,  trading  off  the  attrac¬ 
tive  economics  of  COTS  and  of  custom 
code  written  offshore  against  the  risks  of 
encountering  malware  that  could  seriously 
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jeopardize  future  defense  missions.  The 
current  systems  designs,  assurance 
methodologies,  acquisition  procedures, 
and  knowledge  of  adversarial  capabilities 
and  intentions  are  inadequate  to  the  mag¬ 
nitude  of  die  threat. 

Task  Force  Findings 

The  Industry  Situation 

The  software  industry  has  become 
increasingly  global  as  suppliers  seek  lower 
cost  employees,  access  to  a  larger  talent 
base,  cultures  conducive  to  highly  struc¬ 
tured  processes,  and  round-the-clock 
operation.  The  issue  of  foreign  influence 
is  only  one  of  degree,  because  many  com¬ 
panies  develop  code  in  multiple  geograph¬ 
ic  locations  and  may  embed  code  from 
other  vendors,  code  from  open  source 
developers,  or  even  code  of  unknown 
provenance. 

While  die  United  States  still  has  pre¬ 
eminence  in  computer  science,  Asia  is 
rapidly  gaining.  The  United  States  retains  a 
pool  of  talented  computer  scientists  and 
engineers,  but  the  natural  tendency  of  the 
industry  is  to  seek  the  lowest  cost  supply 
of  talent.  In  recent  years,  diat  has  been 
primarily  in  India,  while  China  and  Russia 
are  on  the  rise. 

DoD’s  Dependence  on  Software 

In  the  DoD,  the  transformational  effects 
of  information  technology  (IT),  joined 
with  a  culture  of  information  sharing, 
called  Net-Centricity,  constitute  a  power¬ 
ful  force  multiplier.  DoD  has  become 
increasingly  dependent  for  mission-critical 
functionality  upon  highly  interconnected, 
globally  sourced,  information  technology 
of  dramatically  varying  quality,  reliability, 
and  trustworthiness. 

Software  Vulnerabilities 

The  majority  of  software  used  in  the  DoD 
are  COTS  products.  Aldiough  the  DoD 
takes  advantage  of  the  functionality  and 
inexpensive  pricing  enabled  by  the  huge 
market,  this  code  has  many  weaknesses 
diat  are  exploitable  by  even  moderately 
capable  hackers  who  have  been  the  bene¬ 
ficiaries  of  a  culture  that  has  produced  an 
evolution  of  widely  disseminated  and 
powerful  tools  for  system  intrusion. 

The  DoD  does  not  fully  know  when 
or  where  intruders  may  have  already 
gained  access  to  existing  computing  and 
communications  systems.  The  Moonlight 
Maze  activities,  which  are  classified  and 
dius  not  detailed  here,  and  numerous 
other  data  points  demonstrate  that  the 
U.S.  government,  and  specifically  the 
DoD  computing  systems,  is  a  constant 
target  of  foreign  exploitation. 


The  Threat  of  the  Nation-State 
Adversary 

In  dealing  with  a  nation-state  adversary,  the 
level  of  threat  rises  far  above  that  posed  by 
hackers.  It  can  be  assumed  diat  the  techno¬ 
logical  capability  to  craft  actionable  mali¬ 
cious  code  mirrors  that  of  die  United 
States’  own  best  computer  scientists.  Means 
and  opportunity  are  present  throughout  the 
supply  chain  and  life  cycle  of  software 
development.  While  code  developed  in  the 
United  States  is  not  immune  from  risk,  the 
opportunity  for  an  adversary  is  greatiy 
enhanced  by  globalization. 

A  sophisticated  adversary  would  have 
diree  possible  aims  in  die  exploitation  of 
existing  or  planted  software  vulnerabili¬ 
ties:  denial  of  service,  stealing  of  informa- 


“ln  a  perfect  world  there 
would  be  some 
automated  means  for 
detecting  malicious  code. 
Unfortunately,  no  such 
capability  exists,  and  the 
trend  is  moving 
inexorably  further  from  it 
as  software  becomes 
even  more  complex  and 
adversaries  more  skilled” 

tion,  and  malicious  modification  of  infor¬ 
mation.  The  outcome  of  any  of  these 
would  also  be  accompanied  by  a  loss  of 
confidence  in  the  DoD’s  essential  systems. 

Awareness  of  the  Software  Assurance 
Threat  and  Risk 

The  DoD’s  defensive  posture  remains 
inadequately  informed  of  the  sophisticat¬ 
ed  capabilities  of  nation-state  adversaries 
to  exploit  globally  sourced,  ubiquitously 
interconnected,  COTS  hardware  and  soft¬ 
ware  within  DoD  critical  systems. 
Similarly,  decision  makers  are  inadequately 
informed  regarding  the  potential  conse¬ 
quences  of  system  subversion,  and  the 
value  of  mitigating  that  risk. 

The  intelligence  community  does  not 
adequately  collect  and  disseminate  intelli¬ 
gence  regarding  the  intents  and  capabili¬ 
ties  of  nation-state  adversaries  to  attack 
and  subvert  DoD  systems  and  networks 


through  supply  chain  exploitations,  or 
through  other  sophisticated  techniques. 

The  DoD  does  not  consistently  or 
adequately  analyze  and  incorporate  into  its 
acquisition  decisions  what  supply  chain 
threat  information  is  available. 

Status  of  Software  Assurance  in  the 
DoD 

Software  deployed  across  the  DoD  con¬ 
tinues  to  contain  numerous  vulnerabilities 
and  weak  information  security  design 
characteristics.  The  DoD  and  its  industry 
partners  spend  considerable  resources  on 
patch  management  while  gaining  only  lim¬ 
ited  improvement  in  defensive  posture. 

The  evidence  gathered  during  this 
study  was  insufficient  to  quantify  the 
extent  to  which  awareness  and  protection 
against  the  system  assurance  problem  has 
permeated  DoD  systems  and  networks. 
The  panel  did,  however,  identity  consider¬ 
able  variation  in  the  extent  to  which  the 
systems  assurance  problem  is  impacting 
next-generation  DoD  systems.  That 
impact  ranges  from  extensive  with  the 
introduction  of  internetworked  COTS 
and  open  source  IT  into  the  Army’s 
Future  Combat  System  program,  to  only 
slight  in  the  United  States  Air  Force  F-22 
program. 

The  DoD  defensive  efforts,  imple¬ 
mented  largely  through  decentralized  exe¬ 
cution,  are  difficult  to  synchronize  to 
achieve  a  coordinated  enterprise  effect. 
The  DoD  has  not  effectively  allocated 
assurance  resources  to  address  the  systems 
assurance  problem,  nor  has  it  designed  its 
systems  and  networks  to  mitigate  this 
problem  in  die  face  of  the  capabilities  of 
nation-state  adversaries. 

The  primary  process  relied  upon  by 
the  DoD  for  evaluation  of  the  assurance 
of  commercial  products  today  is  the 
Common  Criteria  (CC)  evaluation 
process.  The  task  force  believes  that  CC  is 
presently  inadequate  to  sufficiently  raise 
the  trustworthiness  of  software  products 
for  the  DoD.  This  is  particularly  true  at 
Evaluation  Assurance  Level  4  (EAL4)  and 
below,  where  penetration  testing  is  not 
performed.  Nonetheless,  CC  evaluation  is 
an  international  program,  well  established, 
and  not  easy  to  change. 

Ongoing  Efforts  in  Software  Assurance 

Software  assurance  is  receiving  attention 
at  a  number  of  federal  agencies  and  labo¬ 
ratories,  including  the  DoD,  National 
Security  Agency  (NS A),  National  Institute 
of  Standards  and  Technology,  and 
Department  of  Homeland  Security 
(DHS).  Within  the  DoD,  a  Software 
Assurance  Tiger  Team  has  been  studying 
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die  problem  and  has  developed  a  compre¬ 
hensive  strategy  for  managing  risk 
through  system  engineering,  source  selec¬ 
tion,  design,  production,  and  test.  The  key 
element  of  risk  management  in  this  strat¬ 
egy  is  the  prioritization  of  criticality 
among  system  components  and  subcom¬ 
ponents,  with  special  procedures  and 
attention  placed  on  the  system  compo¬ 
nents  determined  to  be  most  critical  to 
mission  success. 

Supplier  Trustworthiness  Considerations 

It  is  not  currently  DoD  policy  to  require 
any  program  -  even  those  deemed  critical 
by  dint  of  a  Mission  Assurance  Category 
I  status  —  to  conduct  a  counterintelligence 
review  of  its  major  suppliers  unless  classi¬ 
fied  information  is  involved.  Supplier 
trustworthiness  enters  into  existing  DoD 
acquisition  processes  primarily  for  protec¬ 
tion  of  classified  information  and  for 
research  technology  protection.  From  a 
systems  assurance  perspective,  supplier 
trustworthiness  should  consider  adversar¬ 
ial  control  and  influence  of  the  business 
or  engineering  processes  of  the  supplier, 
as  well  as  the  ability  of  the  business  and 
engineering  processes  to  prevent  outside 
penetration. 

Finding  Malicious  Code 

The  problem  of  detecting  vulnerabilities 
is  deeply  complex,  and  there  is  no  silver 
bullet  on  the  horizon.  Once  malicious 
code  has  been  implanted  by  a  capable 
adversary,  it  is  unlikely  to  be  detected  by 
subsequent  testing.  A  number  of  software 
tools  have  been  developed  commercially 
to  test  code  for  vulnerabilities,  and  these 
tools  have  been  improving  rapidly  in 
recent  years.  Current  tools  find  about 
one-third  of  the  bugs  prior  to  deploy¬ 
ment  that  are  ever  found  subsequently, 
and  die  rate  of  false  positives  is  about 
equal  to  that  of  true  positives.  However,  it 
is  the  opinion  of  the  task  force  that  unless 
a  major  breakthrough  occurs,  it  is  unlike¬ 
ly  that  any  tool  in  the  foreseeable  future 
will  find  more  than  half  of  the  suspect 
code.  Moreover,  it  can  be  assumed  that 
the  adversary  has  the  same  tools;  there¬ 
fore,  it  is  likely  the  malicious  code  would 
be  constructed  to  pass  undetected  by 
these  tools. 

The  task  force  believes  that  the  acade¬ 
mic  curriculum  in  computer  science  does 
not  stress  adequately  practices  for  quality 
and  security,  and  that  many  programmers 
do  not  have  a  defensive  mindset.  While 
many  vendors  methodically  check  and 
test  code,  they  are  looking  for  uninten¬ 
tional  defects,  rather  dian  malicious  alter¬ 
ations. 


Government  Access  to  Source  Code 

It  is  tempting  to  consider  having  the 
United  States  government  take  the  source 
code  of  a  commercial  product  and  run  its 
own  vulnerability  assessment  tools  against 
it.  However,  there  are  a  number  of  legal, 
ethical,  and  economic  barriers  that  make 
dais  an  unattractive  proposition,  particu¬ 
larly  from  the  point  of  view  of  the  ven¬ 
dor.  License  agreements  forbid  reverse 
engineering  of  source  code,  vendors 
worry  about  the  loss  of  intellectual  prop¬ 
erty,  and  perhaps  most  importantly,  they 
worry  about  the  cost  of  supporting  the 
actions  and  findings  of  a  team  of  out¬ 
siders  not  familiar  with  the  design  and 

“There  is  a  natural 
tension  between  the  U.S. 
government’s  need  to 
know  the  security 
worthiness  of  what  they 
procure  and  a  vendor’s 
need  to  avoid 
disclosing  particular 
vulnerabilities ” 

implementation  of  such  hugely  complex 
programs.  Some  of  these  worries  are  less¬ 
ened  when  the  testing  is  done  by  an  inde¬ 
pendent  laboratory. 

Conclusion 

All  of  the  considerations  just  listed  seem 
to  point  to  an  intractable  problem.  The 
nation’s  defense  is  dependent  upon  soft¬ 
ware  that  is  growing  exponentially  in  size 
and  complexity,  and  an  increasing  per¬ 
centage  of  this  software  is  being  written 
offshore  within  easy  reach  of  potential 
adversaries.  That  software  presents  a 
tempting  target  for  a  nation-state  adver¬ 
sary.  Malicious  code  could  be  introduced 
inexpensively,  would  be  almost  impossible 
to  detect,  and  could  be  used  later  to  get 
access  to  defense  systems  in  order  to  deny 
service,  to  steal  information,  or  to  modify 
critical  data.  Even  if  the  malware  were  to 
be  discovered,  attribution  and  intent 
would  be  difficult  to  prove,  so  the  risk  for 
die  attacker  would  be  small. 

Against  dais  backdrop  of  potential  dis¬ 
aster,  practical  experience  and  belief  paint  a 
picture  of  aggravating  and  continuous  soft¬ 


ware  problems,  but  not  ones  that  are  lethal. 
However,  there  are  some  systems  on  which, 
to  varying  degrees,  life  depends  (e.g,  power, 
health).  In  dais  sense,  DoD  systems  are 
among  the  most  critical  because  their 
national  security  mission  is  often  measured 
in  fatalities,  and  failures  that  would  be 
innocuous  in  another  context  can  be  lethal 
and  lead  to  mission  failure. 

If  the  attacker  cannot  be  deterred  and 
its  malware  cannot  be  found,  what  is  to  be 
done  to  provide  assurance  that  DoD  soft¬ 
ware  will  perform  in  mission-critical  situ¬ 
ations?  Although  there  never  will  be  an 
absolute  guarantee,  software  assurance  is 
really  not  about  absolute  guarantees  but 
rather  intelligent  risk  management.  The 
risk  of  vulnerable  software  can  be  man¬ 
aged  through  a  suite  of  processes  and 
mitigation  strategies  detailed  in  the  Task 
Force  recommendations;  this  risk  can  be 
weighed  against  die  attractive  economics 
and  enhanced  capabilities  of  mass-pro¬ 
duced,  international  software. 

Task  Force  Recommendations 
Acquisition  of  COTS  and  Foreign 
Software 

DoD  should  continue  to  procure  from, 
encourage  and  leverage  die  largest  possi¬ 
ble  global  competitive  marketplace  consis¬ 
tent  with  national  security. 

The  DoD  must  intelligently  manage 
economics  and  risk.  For  many  applica¬ 
tions  the  inexpensive  functionality  and 
ubiquitous  compatibility  of  COTS  soft¬ 
ware  make  it  the  right  choice.  In  acquiring 
custom  software  the  increased  risk  inher¬ 
ent  in  software  written  offshore  may 
sometimes  be  worth  die  considerable  cost 
savings.  The  task  force  recommends  that 
critical  system  components  be  developed 
only  by  cleared  U.S.  citizens. 

Increase  U.S.  Insight  Into 
Capabilities  and  Intentions  of 
Adversaries 

The  intelligence  community  should  be 
tasked  to  collect  and  disseminate  intelli¬ 
gence  regarding  the  intents  and  capabili¬ 
ties  of  adversaries,  particularly  nation¬ 
state  adversaries,  to  attack  and  subvert 
DoD  systems  and  networks  through  sup¬ 
ply  chain  exploitations,  or  through  other 
sophisticated  techniques. 

DoD  should  increase  knowledge  and 
awareness  among  its  cyber-defense  and 
acquisition  communities  of  die  capabili¬ 
ties  and  intent  of  nation-state  adversaries. 

Offensive  Strategies  Can 
Complement  Defensive  Strategies 

The  United  States  government  should 
link  cyber  defensive  and  offensive  opera- 
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dons  to  its  broader  national  deterrence 
strategies,  communications  and  opera¬ 
tions,  treating  adversarial  cyber  operations 
that  damage  United  States  information 
systems  and  networks  as  events  warrant¬ 
ing  a  balanced,  full-spectrum  response. 

System  Engineering  and  Architecture 
for  Assurance 

The  DoD  should  allocate  assurance 
resources  among  acquisition  programs  at 
the  architecture  level  based  upon  mission 
impact  of  system  failure.  The  task  force 
endorses  the  strategy  and  methods  to 
accomplish  this  as  developed  by  the  DoD 
Software  Assurance  Tiger  Team  and  vali¬ 
dated  by  the  Committee  on  National 
Security  Systems  (CNSS)  Global  IT 
Working  Group. 

The  DoD  cannot  cost  effectively 
achieve  a  uniformly  high  degree  of  assur¬ 
ance  for  all  the  functionality  it  uses  across 
many  and  varied  mission  activities. 
Allocating  criticality  of  function  levies  a 
requirement  for  assurance  of  that  func¬ 
tion  and  also  of  those  functions  that 
defend  it.  Systems  identified  as  critical 
must  then  allocate  criticality  at  the  sub¬ 
system  and  assembly  level. 

To  properly  allocate  scarce  assurance 
resources,  the  DoD  must  allocate  critical¬ 
ity  at  die  system-of-systems  and  enter¬ 
prise  architecture  level.  This  analysis 
should  occur  early  within  the  lifecycle,  and 
should  render  a  prioritization  decision  no 
later  than  Acquisition  Milestone  A  to 
allow  programs  of  record  to  appropriate¬ 
ly  respond  to  their  criticality. 

Improve  the  Quality  of  DoD 
Software 

The  DoD  can  effectively  raise  the  signal-to- 
noise  ratio  against  software  attacks  by  rais¬ 
ing  the  overall  quality  of  die  software  it 
acquires.  If  there  were  fewer  unintention¬ 
al  bugs  in  software,  the  visibility  of  delib¬ 
erate  malware  would  be  increased.  While 
general  improvements  in  information 
assurance  will  not,  per  se,  prevent  a  deter¬ 
mined  attacker  from  corrupting  the  soft¬ 
ware  supply  chain,  there  are  several  com¬ 
pelling  benefits  in  improving  the  overall 
assurance/ security  worthiness  of  COTS. 

A  sophisticated  adversary  would  have 
to  work  harder  to  introduce  an  exploitable 
vulnerability  instead,  as  is  currently  the 
case,  of  relying  upon  the  plausible  denia- 
bility  of  a  common  programming  error  to 
avoid  attribution  of  malicious  intent. 
Furthermore,  a  sophisticated  adversary 
would  have  less  confidence  that  its  mal¬ 
ware  would  remain  undetected,  invisible 
in  a  world  containing  far  fewer  distracting 
vulnerabilities.  That  uncertainty  could  be 
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a  deterrent  in  itself. 

Improve  Tools  and  Technology  for 
Assurance 

Improve  Trusted  Computing  Group 
(TCG)  Technologies 

The  TCG  initiatives,  centered  on  the 
Trusted  Platform  Module  (TPM),  provide 
a  means  for  containing  intrusions  into 
separated  information  domains.  Each 
chipset  that  implements  the  TPM  embeds 
a  unique  identifier.  Cryptologic  verifica¬ 
tion  of  this  identity  is  required  when 
access  to  system  assets  is  requested.  TPM 
may  help  ensure  that  only  approved  and 
signed  code  is  run,  thus  reducing  the  risk 
of  unapproved  code  being  installed. 

The  NSA  and  others  have  identified  a 
number  of  improvements  and  comple¬ 
mentary  practices  that  would  strengthen 
TCG-compliant  systems,  including  priva¬ 
cy-preserving  attestation,  virtualization, 
and  architectures  that  provide  richer  soft¬ 
ware  assurance  measurement  and  moni¬ 
toring  capabilities. 

Improve  Effectiveness  of  Common 
Criteria 

Currently,  the  official  DoD-wide  evalua¬ 
tion/validation  scheme  is  the  National 
Information  Assurance  Partnership  based 
upon  the  CC.  The  reality  today  is  that  it 
would  be  far  easier  and  more  effective  to 
improve  CC  than  to  invent  a  new  scheme 
specific  to  the  DoD  or  to  DHS. 

A  number  of  ways  to  strengthen  CC 
are  discussed  in  tire  Recommendations 
section  of  this  report.  Among  these  sug¬ 
gestions  are  crediting  vendors  for  the 
effective  use  of  better  development 
processes,  including  the  use  of  automated 
vulnerability  reduction  tools  and  automat¬ 
ed  tools  for  vulnerability  analysis  during 
EAL4  and  below.  Validation  schemes 
should  also  reduce  artificial  artifact  cre¬ 
ation  and  rely  upon  artifacts  that  are  gen¬ 
erated  by  the  development  process. 

Improve  Usefulness  of  Assurance 
Metrics 

There  is  a  natural  tension  between  tire 
United  States  government’s  need  to  know 
tire  security  worthiness  of  what  they  pro¬ 
cure  and  a  vendor’s  need  to  avoid  disclos¬ 
ing  particular  vulnerabilities.  One  way  to 
satisfy  both  needs  would  be  to  develop  a 
weighted  index  of  the  security  worthiness 
of  software.  A  weighted  score  could  be 
generated  via  testing  based  on  some  com¬ 
bination  of  the  utility  of  the  tools  them¬ 
selves,  the  amount  of  code  coverage  of 
the  tools,  and  the  test  results  against  a  par¬ 
ticular  product.  The  entire  development 
process  should  also  be  evaluated. 


More  Knowledgeable 
Acquisition  of  DoD  Software 

The  DoD  should  implement  a  scalable 
supplier  assurance  process  to  assure  that 
critical  suppliers  are  trustworthy.  No 
product  evaluation  regime  in  effect  today 
provides  insight  into  a  vendor’s  real  devel¬ 
opment  processes  and  their  effectiveness 
at  producing  secure  and  trustworthy  soft¬ 
ware  -  so  the  software  assurance  chal¬ 
lenge  for  the  DoD  is  to  define  an  evalua¬ 
tion  regime  that  is  capable  of  reviewing 
vendors  actual  development  processes 
and  rendering  a  judgment  about  their  abil¬ 
ity  to  produce  assured  software. 

The  DoD  acquisition  process  should 
require  drat  products  possess  assurance 
matching  the  criticality  of  the  function 
delivered.  Furthermore,  the  DoD  should 
require  that  all  components  should  be 
supplied  by  suppliers  of  commensurate 
trustworthiness,  and  in  particular,  that  all 
custom  code  written  for  systems  deemed 
critical  be  developed  by  cleared  U.S.  per¬ 
sonnel. 

The  collective  buying  power  of  the 
United  States  government  is  such  that  it 
can  force  change  on  its  suppliers  to  a 
degree  no  other  market  sector  can  reason¬ 
ably  do.  The  DoD,  working  in  collabora¬ 
tion  with  the  Office  of  Management  and 
Budget,  DHS,  and  other  federal  agencies, 
can  help  to  change  the  market  dynamic 
through  both  positive  and  negative  incen¬ 
tives  so  that  they  get  better  quality  soft¬ 
ware,  and  to  make  better  risk-based  and 
total  fftf/-based  acquisitions. 

Research  and  Development  in 
Software  Assurance 

The  DoD  should  establish  and  fund  a 
comprehensive  science  and  technology 
strategy  as  well  as  programs  to  advance 
the  state-of-the-art  in  vulnerability  detec¬ 
tion  and  mitigation  within  software  and 
hardware.  The  goals  of  the  classified  and 
unclassified  research  and  development 
investments  in  assurance  should  be  to 
develop  the  technology  to  effectively  take 
accidental  vulnerabilities  out  of  systems 
development  and  to  improve  TCG  tech¬ 
nologies  in  order  to  bound  most  risks  of 
intentionally  planted  software.  This  pro¬ 
gram  should  monitor  what  markets  are 
delivering,  identify  gaps  between  what  the 
market  is  delivering  and  what  the  DoD 
needs,  and  fill  the  gap.^ 

For  more  information  on  the  Defense 
Science  Board  Task  Force  findings,  go 
to  <www.acq.osd.mil/dsb>  and  search 
under  “Reports.” 
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